前端工程師一般來說只要搞定 HTML、CSS、Javascript 就可以了，所以後端的環境上不用太在意，但在這幾年的體悟下，這是一個不負責任的想法。

我用過的前端自動化開發環境有：

• Fireapp：這用了有兩年之久，算是一個超級入門 GUI 自動化工具，但在 compass 不維護以後 Fireapp 也不再維護了。
• Prepros：當時 GUI 的自動化工具另一個選擇，到現在還有持續在更新，但一直有些小問題所以沒有想用在專案上，但對於入門來說是個不錯的選擇
• Middleman：為了與 Ruby on Rails 專案做整合，算是不錯的 Command line 工具，也是使用很長的一段時間，現在懶得自己開環境還是會使用。
• *gulp：相當推薦的自動化工具，易學且可以與任何環境結合，缺點是肥了點。
• *webpack：很潮的自動化工具，但與 gulp 觀念差異很大，適合製作 SPA(sigle page application) 的網站。

以下我再將開發流程分為以下三種：

• 後端工程師人肉整合流程：前端工程師射後不理，將 Code 交給後端工程師處理。
• 前後端整合的開發流程：前後端共用相同的開發環境。
• 前後端分離：前後端作業完全分離，後端負責資料庫、API，前端負責頁面結構、API 介接。

後端工程師人肉整合流程

這是很常見的流程，網頁設計師、前端工程師將圖片切完後，交給後端的工程師做整合，後端也許是 PHP、.net、node.js。這樣的缺點在於如果版型不符合後端的需求，後端會直接用 style 的方式直接調整版型，且如果前端發現了問題，也不好修正。

前後端整合的開發流程

有些框架如 Ruby on Rails，就是適合做前後端整合的框架，本身就具有編譯 Sass 的能力，並且有大量的套件可以輔助前端工作。除了 Rails 以外，Gulp 或 Grunt 這樣的自動化工具可以讓前端與後端整合在一起。

這樣的開發流程，前後端的合作會更為密切，大多前端在接觸後也會更深入的了解後端架構，甚至能夠依據需求略為調整資料結構。

前後端分離

自從 Ajax 越來越普遍的情況下，前後端分離漸為許多公司開發的架構，同一個專案會在拆分成前端與後端，這樣完全的分離可以讓職責分得更清楚，但也同時需要更重視 "溝通"。

結語

雖然 CSS 與後端看似關係不大，如果對於開發環境有一定掌控度，也更能掌握元件的細節。最常見的就是設計的結構與資料結構不合需要調整，前端如果對於開發環境掌控度不足，整個在修改所花的時間成本就會相當大。

經常會有前後端或者設計師抱怨其他不同領域的開發者，很多時候在於不夠了解對方，也許會思考 "我時間都不夠了" ，為什麼還要花時間去學對方的領域呢？

換個層面思考，如果了解對方的領域(對方領域的基礎運作即可)，是不是能夠減少更多的溝通成本，進而節省時間。

文章同時發表於：https://wcc723.github.io/css/2016/12/09/css-dev/